In industrial automation installations, communication is increasingly effected by open protocols such as the Internet protocols IP, TCP, UDP, http or CoAP, a protocol for devices having limited resources. Frequently, this involves the use of security protocols based on a public key infrastructure for asymmetric encryption methods using a private and a public cryptographic key. This involves each communication partner being assigned a private key that is used to create a digital signature or to decrypt messages. The corresponding public key is distributed to other communication partners by means of certificates and used for encrypting messages or for checking the digital signature.
Following reception of a certificate, for example with a connection request from a communication partner, the device performs certificate validation. Certificate validation involves checking whether the entries of the certificate are valid, the signature of the certificate has been issued by a trustworthy certification center and said certificate has not been recalled. If all criteria are satisfied, then the certificate is validated. This method allows trustworthy communication with many communication partners, since a communication partner can be authenticated on the basis of its certificate and messages can be transmitted in encrypted form, using the public key embedded in the certificate.
In the industrial automation installations, a field device is not meant to communicate with any other field device that presents a valid certificate from a trustworthy certification center, for example. Permitted communication partners with which such a device can communicate are frequently limited by a positive list, such as a certificate white list or a certificate authorization validation list, for example. DE 10 2014 201 234 A1 describes the production of a positive list of this kind, for example on the basis of the task that a device performs within a network. A positive list of this kind is frequently set up in accordance with a certificate revocation list, in accordance with the RFC3280 or RFC5280 standard.
Typically, certificates have a limited validity period that is typically in the range from several months to a few years. In the course of an update to the certificate of a device, the positive lists of all communication partners of said device need to be updated. To this end, an updated positive list can be sent from the certification center that typically issues the updated certificate to the device, for example. A device that receives an updated certificate can also ask the certification center whether this certificate is valid. This necessitates a large number of update messages that firstly ties up processor capacity in the devices and secondly causes additional load in the transmission network.
Instead of using a positive list, it has hitherto also been known practice to check an identifier from the certificate against an access control list on an access management server. It is likewise known practice to compare an identifier of the certificate with an identifier from the project planning data that are usually provided on a project planning server.
These methods are also linked to a large number of messages between the device and another server, which may be situated within the installation network, but is often also situated outside the closed installation network. Hence, a high level of network traffic is generated and additional processor capacity in the devices is used.